home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1522 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.2 KB
  1. From: bousch@topo.matups.fr (Thierry Bousch)
  2. Subject: Re: Questions and suggestions
  3. Date: Sun, 5 Jun 1994 14:08:36 +0200 (MET DST)
  4. In-Reply-To: <Pine.3.85.9406050042.A7246-0100000@cyber.proxxi.uf.se> from "Elias M}rtensson" at Jun 5, 94 00:37:00 am
  5.  
  6. Hello Elias,
  7.  
  8. > 1: Shouldn't all process files (in /proc) should have 644, not 600. So
  9. > that any user can get full information on them?
  10.  
  11. This would be a security hole, since it would allow you to read all
  12. memory attached to a process (and maybe plaintext passwords, for
  13. instance). On the other hand, there should be some publicly available
  14. information, like the running time and the amount of used memory, but it
  15. isn't the case. Therefore, programs like `ps' and `top' should be made
  16. setuid-root (which causes other security problems, of course).
  17.  
  18. > 2: A nice thing would be if you could change the mode-bits on the
  19. > TOS-filesystem-directories (i.e. u:/c), otherwise, it is impossible to
  20. > create a secure system. Since any user cn change, for example, teh
  21. > mint.cnf file. I would like to set these directories to 700.
  22.  
  23. Julian Reschke has submitted a patch for MiNT 1.10, allowing chmod and
  24. chown on TOS partitions; it works fine, and should be included in MiNT 1.11.
  25.  
  26. > 3: There are a number of system calls that _need_ to be superuser-only.
  27. > The most important of these are of course Super() and Supexec(), because
  28. > as long as any user can execute this instruction, the system can't be
  29. > secure. Other super-only instructions include Dsp_Reset, Dsp_LoadProg,
  30. > Jenabit, Setexec and other system calls that can crash the system.
  31.  
  32. The problem is that Supexec() is used in the startup code of the MiNT
  33. libraries, to scan the cookie jar and determine whether MiNT is running.
  34. Making Supexec() a privileged instruction would break all existing
  35. gcc-compiled programs. 
  36.  
  37. > 4: For these things to work, we need a working setuid-flag of course. I
  38. > was told that the setuid-flag is not yet implented, it it coming?
  39.  
  40. It is implemented and has been working for a long time.
  41.  
  42. > 6: What about implementing a SysV-style sticky-bit on directories? On
  43. > SysV, when the sticky bit is set on a directory, you can't delete files
  44. > in it even if you have write permission on the directory. You must have
  45. > write permission to the file itself also.
  46.  
  47. Torsten Scherer has submitted a patch to handle the sticky bit in the
  48. kernel, but this patch hasn't been integrated into MiNT. It worked,
  49. anyway... Note that the RAMFS filesystem implements the sticky bit (as
  50. well as the setgid bit) for directories.
  51.  
  52. > 8: Should a line be terminated by LF or CR/LF? Personally I don't like
  53. > CR/LF. A good example is the lf-flag (in stty). There is no way that I
  54. > can disable lf->cr/lf mapping because mintlib outputs the cr itself! And
  55. > it's difficult to open stdout/stderr in binary mode.
  56.  
  57. This is a problem with the library, not with MiNT: the CRMODE flag only
  58. applies to tty's. If you want all files (especially stdin and stdout) to
  59. be opened in binary mode, you should add the following line in one of
  60. your .c files:
  61.  
  62.     int __default_mode__ = _IOBIN;
  63.  
  64. > 9: There should be some kind of history for Setexec so that killing a
  65. > process which changes the vbl-routine does not crash when killed.
  66.  
  67. This is tricky. A tentative solution would be to look for dangling
  68. routines when a process terminates (i.e. routines which start in freed
  69. space), and unlink them; but it would require to scan all interrupt and
  70. exception vectors, and to follow them along the XBRA chain. Problems can
  71. occur if this process, instead of hooking to an existant vector,
  72. _installs_ a new interrupt routine (for instance, a printer spooler
  73. could activate the Centronics interrupt source); maybe we could install
  74. a `void' routine, which wouldn't do anything except reset the
  75. appropriate MFP in-service-interrupts bits and return? Or simply ignore
  76. this condition, after all people are not supposed to kill spoolers...
  77.  
  78. A more elegant solution would be to have an additional xbra_install()
  79. system call, so that the kernel could be informed about new vectors;
  80. these vectors would be automagically removed on termination (maybe
  81. calling a user-defined "destructor" to remove the vector properly, if
  82. this removing doesn't only consist in unlinking a hook, but maybe
  83. resetting some MFP state, say). Comments?
  84.  
  85. Thierry.
  86.